InterCD 2000 September/september_2000.iso/intercd/root/^Linux/cfengine-1.5.3/README.install

Text File | 1999-10-15 | 12.2 KB | 336 lines

CFENGINE
--------

Cfengine is a tool for setting up and maintaining BSD and System-5-like
operating system optionally attached to a TCP/IP network.  You can think
of cfengine as a very high level language---much higher level than Perl
or shell: a single statement can result in many hundreds of operations
being performed on multiple hosts. Cfengine is good at performing a lot
of common system administration tasks, and allows you to build on its
strengths with your own scripts. You can also use it as a netwide
front-end for @code{cron}.  Once you have set up cfengine, you'll be
free to use your time being like a human being, instead of playing R2-D2
with the system.

The main purpose of cfengine is to allow you to create a single, central
system configuration which will define how every host on your network
should be configured in an intuitive way.  An interpreter runs on every
host on your network and parses the master file (or file-set); the
configuration of each host is checked against this file and then, if you
request it, any deviations from the defined configuration are fixed
automatically.  You do not have to mention every host specifically by
name in order to configure them : instead you can refer to the
properties which distinguish hosts from one another.  Cfengine uses a
flexible system of ``classes'' which helps you to single out a specific
group of hosts with a single statement.

Cfengine is written and maintained by Mark Burgess, who is very glad to
receive all of the feeback about cfengine, but has less and less time
to work on cfengine.

Bug reports to [e-mail] (News: gnu.cfengine.bug)
General help to [e-mail] (News: gnu.cfengine.help)
Info & fixes at http://www.iu.hioslo.no/~mark/cfengine.html

INSTALLATION
------------

To compile this program, you simply follow the standard GNU configure rules.
At its simpleist, to build and install CFEngine in /usr/local, this would be:

configure
make
make install

There are many options to configure which you can see by giving it the
"--help" argument.  A typical argument is the "--prefix" which will setup
CFEngine to be installed in a directory other than /usr/local.

You may also build CFEngine from a different directory (say /objdir) than the
one containing the source (say /srcdir) by doing the following (note that
this hasn't been significantly tested):

mkdir /objdir
cd /objdir
/srcdir/configure
make
make install

NOTE: the documentation is not built and installed by default.  The configure
script will attempt to determine what tools you have (Tex, Latex, Makeinfo)
and setup doc/Makefile to build everything it can.  However, you may want to
look at what doc/Makefile will do before attempting to run make in that
directory.  If you are satisfied with what doc/Makefile will do, then you can
just do "make install" in the doc directory.

If you have a reasonably complete installation of one of the supported
operating systems, you should not have any problem compiling the software.

Bug reports/info/comments to: [e-mail]

Latest update news on: http://www.iu.hioslo.no/~mark/cfengine.html

Latest patches: ftp.iu.hioslo.no

I reply to all messages that are sent to me, but occasionally I get messages
which I cannot reply to because of errors in the return address. If you don't
receive a reply within a couple of weeks, then you should assume that I was
unable to do so.

PROBLEMS FINDING SHARED LIBRARIES
----------------------------------

The auto configure script is not smart enough to find shared
libraries which do not have a corresponding archive library (.a).
This applies to solaris machines with libthread and libdce for
instance. If configure reports that you do not have these libraries
you need to edit the file config.cache after configure has run
and change 'no' to 'yes' for the relevant libraries, then
do a make.


INSTALLING A NEW VERSION / UPGRADING
------------------------------------

Cfengine does not compile any names based on your choice of
prefix into its code, so when you collect a new version, you
don't *have* to compile with the correct prefix and run
make install. It should be sufficient to do:

configure
make
cp src/cfengine DESTINATION

Version 1.4 and beyond
-----------------------

In this version of cfengine, it is useful to have the tcp-wrappers package
in order to secure access control for network services.

Note that some linux and NetBSD systems have corrupt TCPwrapper libraries
(libwrap) which create unresolved function references at *RUN TIME*
but which appear to compile correctly. Test your compilation before
installing by writing

  src/cfengine -p -v

If you experience this problem, try removing the -lwrap option from
the Makefile and undefining HAVE_TCPD_H, HAVE_LIBWRAP.


NOTE 1.4.*
-----------

 Before installing this verison, add the following line to your /etc/services
 file

  cfengine        5308/tcp


PROBLEMS/TROUBLESHOOTING
------------------------

Although every effort has been made to make the compilation of cfengine
trouble free, you might still encounter some problems where non-standard
features are concerned. The differences between systems is still a major
headache.

It is known, for instance, that versions of gcc after 2.7.0 have a malloc
bug which causes a segmentation fault during parsing. This will not
necessarily show up on all systems. It appears to affect solaris.XF

Earlier versions of the GNU/Linux operating system do not have support
for some of the facilities which cfengine uses.  In particular, the
ability to use NIS netgroups is absent from earlier versions.  During
the installation procedure, the @code{configure} script tests for this
possibility and advises you if the facility cannot be used.  You can
still use cfengine in this case but netgroups will not be expanded.
Another problem with GNU/Linux concerns a special socket call to the
TCP/IP network interface.  This is a command which configures the static
routing table and appears to be absent from all versions of Linux and
newer IRIX versions.  There are also problems with NetBSD.  These
features are undocumented and will be fixed as soon as they have been
understood! If you are running in verbose mode a warning message is
printed, otherwise cfengine will ignore attempts to set a default route
on the system.


A number of users have experienced a problem using flex and bison
in place of lex and yacc. There appears to be a bug in one of these
programs which causes cfengine to compile correctly but misinterpret
its configuration files, generating an error of the form

cfengine:10:action contains invalid statement

for every line! The cure is to collect the latest versions
of flex and bison from your nearest GNU site.

On really old systems, the configure program is not able to guess
what kind of system you are working on. This is true of SunOS
versions 4.0.* and also of BSD 4.3 systems. In such cases, you might
be able to compile cfengine by using the autoconf option `host'
to specify the host-type.

configure --host=sparc-sun-sunos4.0

Some other systems which will compile if forced are:

m68k-hp-bsd4.3
?-?-bsd4.3
romp-ibm-aos
?-?-aos

On BSDI systems, the configure program fails due to differences
in the shell. Here is a fix, straight from the horses mouth!
==BEGIN=====================

Mark,

   To correct this for BSDI I replaced the following script fragment from
configure:

-------------------------------------------------------------------------
#
# Add to the default list of places in LDFLAGS to compensate for
# ... the configure default value of LIBS on some systems
#
for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
do
  if test -d "$x"; then
    y=`expr match "$LDFLAGS" ".*-L$x"`
    if test $y -eq 0; then
      LDFLAGS="$LDFLAGS -L$x"
    fi
  fi
done

#
# Add to the default list of places in CPPFLAGS to match LDFLAGS above
#
for x in /usr/include /usr/local/gnu/include /usr/local/include
do
  if test -d "$x"; then
    y=`expr match "$CPPFLAGS" ".*-I$x"`
    if test $y -eq 0; then
      CPPFLAGS="$CPPFLAGS -I$x"
    fi
  fi
done
------------------------------------------------------------------------

   With this script fragment, which successfully executed:

------------------------------------------------------------------------

#
# Add to the default list of places in LDFLAGS to compensate for
# ... the configure default value of LIBS on some systems
#
for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
do
  if test -d "$x"; then
    case $LDFLAGS in
    .*-L$x)
      LDFLAGS="$LDFLAGS -L$x"
      ;;
    esac
  fi
done

#
# Add to the default list of places in CPPFLAGS to match LDFLAGS above
#
for x in /usr/include /usr/local/gnu/include /usr/local/include
do
  if test -d "$x"; then
    case $CPPFLAGS in
    .*-I$x)
      CPPFLAGS="$CPPFLAGS -I$x"
      ;;
    esac
  fi
done
-----------------------------------------------------------------------


==END=======================

On some systems, problems arise when using flex. Flex might
generate a lexer file lex.yy.c which defines malloc or some other
function to be of a type which conflicts with the system definition.
If you obtain such a culture crash, edit the lexer file manually
and simply delete the offending definitions, then run make again.

As of version 1.4.0 cfengine tries to link in features based on the
Berkeley database library @file{libdb} and the TCP wrappers library
@file{libwrap}.  If you want to use these facilities, you will have to
collect them and install them before compiling cfengine.  Some
problems have been experienced with the linux version of TCP
wrappers. If you experience compilation problems, the best thing to do
is to edit @file{src/conf.h} after configuration and remove the line
beginning @samp{#define HAVE_LIBWRAP}.

Newer solaris systems have ACLs. The ACL features only matured in version
2.5 of solaris however, and there have been some problems with the
partial implementation in 2.4. If you obtain error messages about unknown
ACL functions, edit the @file{config.cache} file in the cfengine root
directory and set the value:

ac_cv_header_sys_acl_h=${ac_cv_header_sys_acl_h='no'}


If you use the DCE (Distributed computing environment) cfengine will try to
compile the ACL extension for DFS. This requires the DCE library to be present
on the system on which you are compiling. On some systems it also requires
thread libraries to be present. Unfortunately, the autoconf program
which generates the Makefiles cannot detect shared libraries, only archive
libraries. This means that you need to edit the @file{config.cache} file
to compile in this support. Set the following values:

ac_cv_lib_dce_main=${ac_cv_lib_dce_main='yes'}
ac_cv_lib_dce_main=${ac_cv_lib_thread_main='yes'}


--------------------------------------------------------------------

Problems compiling on IRIX

Subject: [1.4.10] with gcc-2.8.0 on irix6.x
    Date: 24 Feb 1998 16:53:02 GMT
      To: [e-mail]


gcc-2.8.0 produces '-n32' formatted object files, which need to be linked
with libraries in /usr/lib32.  The linker finds /usr/lib or /usr/lib32
according to the formats it finds, unless an explicit -L/usr/lib is
applied.  For this reason, it is disastreous to add -L/usr/lib as it forces
the linker to take the libraries with -o32 objects

Here is a rough-and-ready patch which got 1.4.9 and 1.4.10 to build
properly for me.

--- benedict

--- cfengine-1.4.9.orig/configure.in    Wed Dec 24 11:43:45 1997
+++ cfengine-1.4.9/configure.in    Wed Feb  4 09:33:24 1998
@@ -16,7 +16,7 @@
 # Add to the default list of places in LDFLAGS to compensate for
 # ... the configure default value of LIBS on some systems
 #
-for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
+for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib
 do
   if test -d "$x"; then
     y=`expr match "$LDFLAGS" ".*-L$x"`

--
Benedict Lofstedt     <[e-mail]>
Computer Science Department, Aarhus University,   Fax: + 45 8942 3255
Ny Munkegade, DK-8000 Aarhus C, Denmark.        Phone: + 45 8942 3222


Mark Burgess

12/12/97